home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 2001 May / SGI Freeware 2001 May - Disc 1.iso / dist / patchSG0003911.idb / usr / share / catman / u_man / cat1 / mipscheck.z / mipscheck
Text File  |  2001-01-10  |  15KB  |  289 lines
  1. MIPSCHECK(1)                                          Last changed: 4-27-99
  2.  
  3.  
  4. NNAAMMEE
  5.      mmiippsscchheecckk, rr88kkpppp, rr55kkpppp, uu6644cchheecckk - Examines binaries for instruction
  6.      sequences
  7.  
  8. SSYYNNOOPPSSIISS
  9.      mmiippsscchheecckk [--vv]  [-_c_o_n_d_i_t_i_o_n[:_a_c_t_i_o_n...] ... ] _f_i_l_e_s
  10.  
  11.      rr88kkpppp [--vv]  [-_c_o_n_d_i_t_i_o_n[:_a_c_t_i_o_n...] ... ] _f_i_l_e_s
  12.  
  13.      rr55kkpppp [-_v]  [-_c_o_n_d_i_t_i_o_n[:_a_c_t_i_o_n...] ... ] _f_i_l_e_s
  14.  
  15.      uu6644cchheecckk [--vv]  [-_c_o_n_d_i_t_i_o_n[:_a_c_t_i_o_n...] ... ] _f_i_l_e_s
  16.  
  17. IIMMPPLLEEMMEENNTTAATTIIOONN
  18.      IRIX systems
  19.  
  20. DDEESSCCRRIIPPTTIIOONN
  21.      _m_i_p_s_c_h_e_c_k examines binaries for instruction sequences that may have
  22.      processor specific behavior.  It reports which conditions it found,
  23.      and in certain cases, will modify the sequence so that the binary
  24.      behaves consistently on all platforms.  On exit, mmiippsscchheecckk returns an
  25.      exit status which is the number of occurrences of the specified
  26.      condition(s) found.
  27.  
  28.      --vv Generates verbose output, including the address of each problem
  29.      found.
  30.  
  31.      _m_i_p_s_c_h_e_c_k Operates on object files, archives files, executables, and
  32.      DSOs.
  33.  
  34.      Specifying _r_8_k_p_p, _r_5_k_p_p, _u_6_4_c_h_e_c_k are alternative ways of invoking
  35.      _m_i_p_s_c_h_e_c_k which imply default values designed specifically for the
  36.      specified architecture.
  37.  
  38. CCOONNDDIITTIIOONNSS
  39.      --pprreeff[:_a_c_t_i_o_n...]   Look for and remove prefetch instructions.
  40.  
  41.      The pprreeff and pprreeffxx prefetch instructions are part of the mips4
  42.      instruction set.  They are fully implemented on the r10000 and the
  43.      r5000 but are not supported on r8000 based machines.  See the r8000
  44.      errata sheet for more details.
  45.  
  46.      The default actions are:  --pprreeff::cchheecckk::nnooffoorrccee::rreeppaaiirr
  47.  
  48.      --mmffhhiilloo[:_a_c_t_i_o_n...]
  49.           Look for instructions that reference the HI or LO registers and
  50.           are one or two instructions after a mmffhhii or mmfflloo instruction.
  51.  
  52.           The mips1, mips2, and mips3 instruction sets specify that there
  53.           is a two instruction hazard between a mmfflloo instruction and a
  54.           following instruction that references the LO register.  This
  55.           hazard was removed from the mips4 instruction set (that is, it
  56.           was up to the processor to supply the hardware interlock).  The
  57.           r8000 and the r10000 have this hardware interlock but the r5000
  58.           does not; this requires the compiler to continue to enforce the
  59.           scheduling hazard.
  60.  
  61.      It is possible that Irix 6.1 64bit binaries may have this relaxed
  62.      instruction scheduling sequence.  As of Irix 6.2, all SGI compilers
  63.      generate code that does not depend upon the processor handling the
  64.      hardware interlock, but rather the compilers schedule the instructions
  65.      to avoid it.  See the r5000 errata sheet for more details.
  66.  
  67.      The default actions are:  --mmffhhiilloo::cchheecckk::nnooffoorrccee::nnoorreeppaaiirr
  68.  
  69.      --ccvvttll[:_a_c_t_i_o_n...]
  70.           Look for cvt.s.l and cvt.d.l instructions.  These instructions
  71.           convert 64-bit integers to single or double floating point
  72.           format.
  73.  
  74.      Revision [1.1] of the r5000 can misexecute cvt.s.l and cvt.d.l
  75.      instructions when the 64-bit integer input data is in either of the
  76.      following ranges:
  77.  
  78.           0x7FF0 0000 0000 0000    to    0x7FFF FFFF FFFF FFFF
  79.           0x8000 0000 0000 0000    to    0x800F FFFF FFFF FFFF
  80.  
  81.      When input data is in the preceding ranges, these instructions are
  82.      supposed to trap into the kernel where they will be emulated in
  83.      software.  Unfortunately, they do not trap and they generate an
  84.      incorrect result.  These instructions are fairly rare and are found in
  85.      mips3 and mips4 executables only; they are never in mips1 or mips2
  86.      programs.  There is a work-around for this problem, implemented
  87.      entirely within the operating system kernel, which should be invisible
  88.      to all user programs.  See the r5000 errata sheet for more details.
  89.  
  90.      The default actions are:  --ccvvttll::cchheecckk::nnooffoorrccee::nnoorreeppaaiirr
  91.  
  92.      --ffmmuullmmuull[:_a_c_t_i_o_n]
  93.           Look for a floating point multiply immediately followed by a
  94.           floating point or integer multiply.
  95.  
  96.           Very early versions of the r4300 (used only in the Nintendo
  97.           Ultra64 Game Player) could mis-execute the second multiply
  98.           instruction when the first multiply encountered a NaN or an
  99.           Infinity operand.  See the r4300 errata sheet for more details.
  100.  
  101.           The default actions are:  --ffmmuullmmuull::cchheecckk::nnooffoorrccee::nnoorreeppaaiirr
  102.  
  103.      --iiddiivvmmuull[:_a_c_t_i_o_n]
  104.           Look for integer divides and multiplies in branch-delay slots or
  105.           preceding a branch-target.
  106.  
  107.           On the r10000, under extremely rare conditions, if an integer
  108.           multiply or integer divide is interrupted, the EPC (Exception
  109.           Program Counter) will point to the instruction following the
  110.           multiply/divide and the HI register will not be updated.  There
  111.           is a work-around for this problem implemented entirely within the
  112.           operating system kernel, which should be invisible to all user
  113.           programs.  See the r10000 errata sheet for more details.
  114.  
  115.           The default actions are:  --iiddiivvmmuull::cchheecckk::nnooffoorrccee::nnoorreeppaaiirr
  116.  
  117. AACCTTIIOONNSS
  118.      Each condition has an optional colon (:) separated list of actions
  119.      associated with it.  _a_c_t_i_o_n can be any of the following:
  120.  
  121.      cchheecckk
  122.           Check for the specified condition (default action).
  123.  
  124.      nnoocchheecckk
  125.           Do not check for the specified condition.
  126.  
  127.      ffoorrccee
  128.           Examine the instruction sections for the condition even if
  129.           mmiippsscchheecckk has other means of determining that the condition does
  130.           not exist.  For example, an instruction sequence involving mips4
  131.           instructions could not exist in a mips3 executable.  ffoorrccee
  132.           instructs mmiippsscchheecckk to search for the condition anyway.
  133.  
  134.      nnooffoorrccee
  135.           Do not examine the instruction sequences unless necessary
  136.           (default action).
  137.  
  138.      rreeppaaiirr
  139.           Modify the instruction sequence so that it does not hit the
  140.           specified condition.  This action is valid only with the --pprreeff
  141.           condition.
  142.  
  143.      nnoorreeppaaiirr
  144.           Do not modify the code (default action).
  145.  
  146.      If a condition is specified with no actions, mmiippsscchheecckk assumes the
  147.      default actions.  For example, specifying --mmffhhiilloo is equivalent to
  148.      --mmffhhiilloo::cchheecckk::nnooffoorrccee::nnoorreeppaaiirr.
  149.  
  150. EEXXIITT CCOODDEESS
  151.      mmiippsscchheecckk terminates with an exit code set to the number of conditions
  152.      found.  For example, if it found 10 --mmffhhiilloo problems, it would
  153.      terminate with an exit code of 10.  In the case of rr88kkpppp,, this may be
  154.      a little misleading because the command has not only found each of the
  155.      problem conditions but it has repaired them as well.  If you were to
  156.      run rr88kkpppp on the binary a second time, no conditions would be reported
  157.      because the binary has been patched.
  158.  
  159. EEXXAAMMPPLLEESS
  160.      The following example shows how to build a mips4 binary and verify
  161.      that there are no prefetch instructions:
  162.  
  163.           % cc -mips4 -n32 -o bean bean.c
  164.           % mipscheck -pref:check:norepair bean
  165.           % echo $status
  166.  
  167.      The following example shows how to compile a file to be linked into an
  168.      Ultra64 Game program and verify that there are no dangerous multiply
  169.      pairs:
  170.  
  171.           % cc -mips2 -32 -c bean.c
  172.           % mipscheck -fmulmul:check:norepair bean.o
  173.           % echo $status
  174.  
  175.      This example examines the location of the ccvvttll problem(s) in the
  176.      //bbiinn//sshh program.
  177.  
  178.           % mipscheck -v -cvtl:check:norepair:force /bin/sh
  179.           mipscheck [1.6]
  180.           /bin/sh: r5000 cvt.d.l cvt.s.l  problem at 0x100138d0
  181.           cvtl found   : 1
  182.  
  183.      By invoking rr88kkpppp, you are specifying that all r8000 specific
  184.      conditions should be checked for and repaired.  This is equivalent to
  185.      specifying the following:
  186.  
  187.           % mipscheck -pref:check:noforce:repair  myprog
  188.  
  189.      By invoking rr55kkpppp, you are specifying that all r5000 specific
  190.      conditions should be checked for and reported.  This is equivalent to
  191.      specifying the following:
  192.  
  193.           % mipscheck -mfhilo:check:noforce:norepair  \
  194.                  -cvtl:check:noforce:repair myprog
  195.  
  196.      By invoking uu6644cchheecckk, you are specifying that all r4300 specific
  197.      conditions should be checked for and reported.  This is equivalent to
  198.      specifying the following:
  199.  
  200.           % mipscheck -fmulmul:check:noforce:norepair  myprog
  201.  
  202. FFIILLEESS
  203.      //uussrr//ssbbiinn//mmiippsscchheecckk   mmiippsscchheecckk executable
  204.      //uussrr//ssbbiinn//rr88kkpppp       Symbolic link to //uussrr//ssbbiinn//mmiippsscchheecckk
  205.      //uussrr//ssbbiinn//rr55kkpppp       Symbolic link to //uussrr//ssbbiinn//mmiippsscchheecckk
  206.      //uussrr//ssbbiinn//uu6644cchheecckk    Symbolic link to //uussrr//ssbbiinn//mmiippsscchheecckk
  207.  
  208. UUNNEEXXPPEECCTTEEDD BBEEHHAAVVIIOORR
  209.      The --ffmmuullmmuull option may give a false positive in the case of a
  210.      floating point multiply instruction in a branch delay slot.  The
  211.      mmiippsscchheecckk program does not look at the target of the branch and so
  212.      must assume that the branch target may be another multiply
  213.      instruction.
  214.  
  215.      The --pprreeff::ffoorrccee option will almost always give false positives because
  216.      it will report on every prefetch instruction found instead of just the
  217.      combinations of prefetches that can lead to mis-execution on an r8000.
  218.  
  219.      Because mmiippsscchheecckk cannot examine input data for data-dependent
  220.      problems, it must report on instruction sequences that may fail under
  221.      the proper conditions.  For example, mmiippsscchheecckk will report all ccvvtt..dd..ll
  222.      instructions, not just the ones that may get bad input data.
  223.  
  224.      Similarly, because mmiippsscchheecckk cannot know about tlb-miss and cache-miss
  225.      behavior, it must report on instruction sequences that might trigger
  226.      the r4000 branch-at-end-of-page problem even though the actual
  227.      conditions required to hit it are quite rare.
  228.  
  229. NNOOTTEESS
  230.      "Do I need to worry about this stuff?"  is a valid question.  In
  231.      general, the answer is no.  But SGI developers and some customers who
  232.      have access to early revisions of systems may need this tool to help
  233.      identify and/or repair problems.  The following are some relevant
  234.      cases:
  235.  
  236.      1. Irix 6.1 binaries compiled with --nn3322 --mmiippss44 that are moved to an
  237.         r5000 system should be checked with rr55kkpppp.. There should be no such
  238.         binaries in the field; but because experimental systems and
  239.         experimental compilers were available, it is possible that such
  240.         binaries exist.
  241.  
  242.      2. The Irix 6.2 (and later) operating systems for r8000s will
  243.         automatically patch any running program to remove the prefetch
  244.         instructions.  This will not affect the performance on an r8000 but
  245.         it will avoid the r8000 prefetch problem.  In rare cases, the
  246.         kernel will not be able to avoid the problem and will request that
  247.         the user run the binary through rr88kkpppp to execute the repair
  248.         permanently.
  249.  
  250.      3. Ultra64 game developers should always run _u_6_4_c_h_e_c_k to locate cases
  251.         where their assembly code violates the game player's hardware
  252.         restrictions.
  253.  
  254.      4. Irix 6.2 binaries compiled using --mmiippss33 or --mmiippss44, using 64-bit
  255.         integers, and running on Revision [1.1] of the r5000 may, in rare
  256.         cases, encounter the cvtl problem.  The kernel handles this case
  257.         but incurs a small overhead for checking on this condition.  The
  258.         overhead should be negligible.  If _r_5_k_p_p finds no problem in an
  259.         executable, it will mark the executable as "clean", which helps the
  260.         kernel eliminate the overhead.
  261.  
  262.      5. On all MIPS processors, when an instruction is interrupted, the EPC
  263.         (Exception Program Counter) points to the interrupted instruction.
  264.         The exception to that rule is when the interrupted instruction is
  265.         in a branch-delay slot, in which case the EPC points to the
  266.         previous branch instruction.  On an r10000, if the kernel ever
  267.         detects a "bad" EPC for an interrupted integer multiply or integer
  268.         divide, the kernel will silently (and at no measurable performance
  269.         cost) repair the EPC  and the damaged HI register.  If the
  270.         interrupted instruction is in a branch-delay slot of an
  271.         unconditional branch, the kernel may not be able to repair the EPC
  272.         and will abort the program, reporting the result in the SYSLOG.
  273.  
  274.      To make it easier for the kernel to detect and repair the EPC in these
  275.      cases, the compiler will not put an integer multiply or divide in a
  276.      branch delay slot of an unconditional branch, nor will it make the
  277.      following instruction a branch target.  Versions 6.2 through 7.2 of
  278.      the SGI compilers occasionally break these rules when generating code
  279.      --mmiippss44.  This is not a problem but it makes it more difficult for the
  280.      kernel to detect and repair the problem.  Compiler versions 7.2.1 and
  281.      later always obey these two rules.
  282.  
  283. SSEEEE AALLSSOO
  284.      eellffdduummpp(1)
  285.  
  286.      hhttttpp::////wwwwww..mmiippss..ccoomm for information on chips.
  287.  
  288.      This man page is available only online.
  289.